! J11 Ull I II III 11 1 I II 1UI III IH IH II I llll ni I II IBI 

US006308274B1 

(12) United States Patent m Patent No.: us 6,308,274 bi 

Swift (45) Date of Patent: Oct. 23, 2001 



(54) LEAST PRIVILEGE VIA RESTRICTED 
TOKENS 



(75) Inventor: Michael M. Swift, Seattle, WA (US) 



(73) Assignee: Microsoft Corporation, Redmond, WA 
(US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 



(21) Appl. No.: 09/096,679 



(22) Filed: Jun. 12, 1998 



(51) Int. CI. 7 G06F 12/14; G06F 1/00; 

G06F 13/00; G06F 15/40 

(52) U.S. CI 713/201; 713/200; 713/169; 

713/159; 713/172; 713/173; 713/170; 710/200; 
710/220; 710/241; 710/242; 710/243; 710/244 

(58) Field of Search 713/200, 201, 

713/169, 170, 172, 173, 159; 710/240, 
200, 220, 241, 242, 243, 244 

(56) References Cited 

U.S. PATENT DOCUMENTS 
4,962,449 10/1990 Schlesinger . 

5,138,712 ♦ 8/1992 Corbin 713/200 

5,276,901 * 1/1994 Howell et al 707/9 

(List continued on next page.) 

FOREIGN PATENT DOCUMENTS 

0 398 645 11/1990 (EP) . 

0 465 016 1/1992 (EP) . 

0 588 415 3/1994 (EP) . 

0 697 662 2/1996 (EP) . 



(list continued on next page.) 

OTHER PUBLICATIONS 

Frost, Jim "Windows NT Security", May 1995, pp. 1-5, 
retrieved on Jun. 27, 2001 from the Internet <http://world- 
j5td.conV-jim£^apers/nt-security/nt-security.html>. 
Asche, Ruediger R. "Windows NT Security in Theory and 
Practice", May 1995, pp. 1-14, retrieved on Jun. 27, 2001 
from the Interaet<http://msdn.micrc^ft.coni/u*brary/te- 
chart/msdn-seccpp .htm> . 

Asche, Ruediger R. "The Guts of Security", May 1995, pp. 
1-26, retrieved on Jun. 27, 2001 from the Internet: <http:// 
msdn.microsoft.com/library/techart/insdn_secguts.htm>. 

(List continued on next page.) 

Primary Examiner — Thomas Lee 

Assistant Examiner — Katharina Schuster 

(74) Attorney, Agent, or Firm-^Iichalik & Wylie, PLLC 

(57) ABSTRACT 

A method and mechanism to enforce reduced access via 
r estricted access tokens. Restricted access tokens are based 
on an existing token^and have less access than that exist ing 
token. A process is associated with a restri cted token, and 
wtienthe restricted p rocess attem ptsjoperform an action on 
a resource, a securit y mechanism compares~the access tok en 
information w ith security information associated with the 
resou rce to grant or deny ac cess. Application programs may 
have restriction information stored in association therewith, 
such that when launched, a restricted token is created for that 
application based on the restriction information thereby 
automatically reducing that application's access. Applica- 
tions may be divided into different access levels such as 
privileged and non-privileged portions, thereby automati- 
cally restricting the actions a user can perform via that 
application. Also, the system may enforce running with 
reduced access by running user processes with a restricted 
token, and then requiring a definite action by the user to 
specifically override actions that are restricted by tempo- 
rarily running with the user's normal token. 

43 Claims, 11 Drawing Sheets 




06/05/2003, EAST Version: 1.03.0002 



US 6,308,274 Bl 

Page 2 



U.S. PATENT DOCUMENTS 

5,321,841 6/1994 East et al. . 

5,390,247 2/1995 Fischer. 

5,412,717 5/1995 Fischer. 

5,506,961 ♦ 4/19% Carlson et al 713/200 

5,542,046 ♦ 7/1996 Carlson et al 713/200 

5,638,448 6/1997 Nguyen. 

5,649,099 7/1997 Theimer et al. . 

5,675,782 * 10/1997 Montague et al 713/201 

5,678,041 • 10/1997 Baker et al 707/9 

5,680,461 10A997 McManis . 

5,682,478 10/1997 Watson et al. . 

5,745,676 • 4A998 Hobson et al 713/200 

5,757,916 5/1998 MacDoran et al. . 

5,761,669 6/1998 Montague et al. . 

5,812,784 9/1998 Watson et al. . 

5,826,029 * 10/1998 Gore, Jl et al 709/227 

5,845,067 12/1998 Porter et aL . 

5,922,073 7/1999 Shimada . 

5,925,109 ♦ 7/1999 Bartz 710/14 

5,940,591 8/1999 Boyle et al. . 

5,941,947 * 8/1999 Brown et al 709/225 

5,949,882 * 9/1999 Angelo 713/200 

5,983,270 11/1999 Abraham et al. . 

5,983,350 11/1999 Minear et al. . 

6,081,807 • 6/2000 Story et al 707/101 

6,105,132 8/2000 Fritch et al. . 

FOREIGN PATENT DOCUMENTS 

0 813 133 12/1997 (EP) . 

WO 96/05549 2/1996 (WO). 

WO 96/13113 5A996 (WO). 

WO 97/15008 4/1997 (WO). 

WO 97/26734 7/1997 (WO). 

OTHER PUBLICATIONS 

Soshi et al. "The Saga Security System: A Security 
Architechture for Open Distributed Systems", IEEE, 1997, 
pp. 53-58.* 

"Java Security Model: Java Protection Domains,** http:// 
java.sun.com/security/handout.html, printed Nov. 11, 1999. 
Anon, "Privilege Control Mechanism for UNIX Systems," 
IBM Technical Disclousure Bulletin, vol34, No. 7b pp. 
477-^79, Dec 1991. 

Erdos et al, "Security Reference Model for the Java Devel- 
oper's Kit 1.0.2 " Java Security Reference Model, Nov. 13, 
1996, http://ww.javasoft.com/security/SRM.html printed 
Jul. 14, 1999. 



Fritzinger et al., "Java Security" 1996, http://java.suo.com/ 
security/whitepaper.txt. 

Mazieres, David and M. Frans Kaashoek, "Secure Applica- 
tions Need Flexible Operating Systems," 6th Workshop on 
Hot Topics in Operating Systems (HotOS-VI) t May 5-6, 
1997, http://www.eecs.harvard.edu/hotos/. 

Goldstein, Ted, "The Gateway Security Model in the Java 
Commerce Client/' The Source for Java ^Technology, 
1997, http://www.java.sun.com/products/commerce/docs/ 
whitepapers/security/JCC_gateway.html printed Jul. 14, 
1999. 

Mazieres, David and M. Frans Kaashoek, "Secure Applica- 
tions Need Flexible Operating Systems,"6th Workshop on 
Hot Topics in Operating Systems (HotOS-VI), May 5-6, 
1997, http://www.eecs.harvard.edu/hotosA 

Neuman et al., "Kerberos: An Authentication Service for 
Computer Networks," IEEE Communications magazine, pp. 
33-38, Sep. 1, 1994. 

copy of International Search Report in Corresponding PCT 
application No. PCT/US99/12914. 

Anonymous, "Apache suEXEC Support," (describes the 
Apache HTTP Server Version 1.3 dating from Jun. 5, 1998 
as documented in Written Opinion for PCT Application No. 
PCT/US99/129 12), <htty://www.apache.org/docs/suex- 
ec.html>,printed Jul. 24, 2000. 

Anonymous, "Apache Virtual Host documentation," 
(describes the Apache HTTP Server Version 1.3 dating from 
Jun. 5, 1998 as documented in Written Opinion for PCT 
Application No. PCT/US99/12912), <http://www.apa- 
che.org/docs/vhosts/index.html>,printed Jul. 24, 2000. 

Bell Telephone Laboratories Incorporated, 
UNDC™Time-Sharing System: UNIX Programmer's 
Manual, 7 th Edition, vol. 1, CHMOD(l), Su(l), Exec(2) 
(Jan. 1979). 

Fritzinger et al., "Java Security,"1996,<http://5 ava.sun.com/ 
security/whitepaper.txt>. 

Fritzinger et al., "Java Security,"1996,<http://j ava.sun.com/ 
security/whitepaper.ps>. 

* cited by examiner 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct 23, 2001 Sheet 1 of 11 



US 6,308,274 Bl 




06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct 23, 2001 Sheet 2 of 11 US 6,308,274 Bl 



TOKEN 



User SID 



Groups SID 



Group2 SID 



Group n SID 



Privilege^ 
Prlvllege2 



Privilege m 



Token ID 




Create 
Restricted 
Token 
API 



68 



90 



92 



RESTRICTED TOKEN 






User SID 


GroiiD^ SID 


Group* SID 

■ Mm 

DEN YON LY 


■ 


Groups SID 








.X 










Restricted SID 1 




Restricted SID 2 


Restricted SID 3 




Restricted SID r 








Token ID 


Parent Token ID 



FIG. 2 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent oct.23,2001 sheet 3 of 11 



US 6,308,274 Bl 



£Z 



84 



RESTRICTED TOKEN 




User SID 

Group-) SID 






Group 2 SID (DENY) 






Group n SID 






Privilege-) 






Restricted SID-| 






Restricted SID2 






Restricted SID3 






■ 

Restricted SID r 







PROCESS 



70 



PROCESS 



72 
76 



.88 



80 



81 



r 



94 



-60 



TOKEN 



OBJECT 
MANAGER 



OBJECT 



SECURITY 
DESCRIPTOR 



Header 



Owner 



DACL 



Entry.) 
Entry n 



SACL 



Entryj • 
Entry m - 



1 



i 



SECURITY 
MECHANISM 



78 



-3- 



FIG. 3 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct 23, 2001 Sheet 4 of 11 



US 6,308,274 Bl 



FIG. 4A 



402 



Yes 



Mark All 
Groups as 
Deny Only 



412 



Yes 



Delete All 
Privileges 



416 




Mark SIDs Listed In 
Both Parent Token 
and SidToDisable 
Field as Deny Only 




Remove Privileges 
_ Listed In Both Parent 

Token and 
PrivilegesToPel ete Field 

-» (T0FIG.4B J * 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent 



Oct. 23, 2001 Sheet 5 of IT US 6,308,274 



FIG. 4B 



( FROM FIG. 4A j 




Put SIDs Listed In Both 
Parent Token and 
RestrictedSids 

Input Field (Intersection) 
Into RestrictedSids 
Field of New Token 



Put SIDs Listed In 
RestrictedSids 
Input Field Into 
RestrictedSids 
Field of New Token 



430 



Set Parent Token ID 
of New Token to 
Token ID of 
Parent Token 



Q end ) 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct. 23, 2001 Sheet 6 of ll 



US 6,308,274 Bl 



84 



72 



90 



\ 



92 



RESTRICTED TOKEN 



User ID: 
VBaker 



Group IDs: 
Teaml 
Accounting 
Basketball (DENY) 
Corporate 



Privileges: 
Set System Clock 



Restricted SIDs: 
Internet Explorer 



80 



88 



OBJECT 



ACL 



XJones 


(DENY ALL) 


SJohnson 


(RO) 


VBaker 


(WR, SYNC) 


Teaml 


(RO) 


Team2 


(RO, SYNC) 


Accounting 


(WR, SYNC) 


Corporate 


(WR, SYNC) 


Finance 


(RO, SYNC) 


MSWord 


(WR) 


MSExcel 


(RO) 



PROCESS 



r 



94 



74 



(ACCESS). 



(OBJECT ID). 



(RESULT) 



OBJECT 
MANAGER 



SECURITY 
MECHANISM 



78 



FIG. 5 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent 



Oct. 23, 2001 



Sheet 7 of 11 



US 6,308,274 Bl 



76 



96 



SECURITY 
DESCRIPTOR 



DESIRED 
ACCESS 



84 



TOKEN 



98 



NORMAL ACCESS 
CHECK 

(Normal SIDs in Token, 
USE_FOR_DENY_ONLY) 



100 



RESTRICTED SIDS 
ACCESS CHECK 
(Restricted SIDs In Token) 




Granted 
Access 

FIG. 6 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct. 23, 2001 Sheet 8 of 11 



US 6,308,274 Bl 



FIG. 7 



(begin ) 
f w — r — y 



Receive Type of 
Access Desired 



702 



v.. 



Perform UserAndGroup 
Access Check 
Against ACL 



712 




Perform Restricted SIDs 
Access Check A 
Against ACL 




Grant Access 
(Return Handle 
to Object) 



A 4 



Deny Access 



■GD- 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct. 23, 2001 



Sheet 9 of 11 US 6,308,274 Bl 



112 



110 



RESTRICTION 
INFORMATION 



114 



APPLICATION 
PROGRAM 



RESTRICTED 
TOKEN „ 




122 



RESOURCES 



•124 



FIG. 8 



130 





PrMleaed Portion 


Non-Prlvileaed Portion 




Add new features 


Enter Data 


132 


Set Default Behavior 


Save Data to File 




APPLICATION 


FIG. 10 





134 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct. 23, 2001 Sheet 10 of 11 US 6,308,274 Bl 



122- 



124 



RESTRICTED TOKEN 



User ID: 
G Player 



Group IDs: 
Teaml 
Accounting 
Corporate 



Privileges: 
NULL 



Restricted SIDs: 
GAME33 



RESOURCE 


OBJECT 


(Game File) 






ACL 






GPIayer 


(WR, SYNC) 






Teaml 


(RO) 






GAME33 


(WR) 









Game Application Program f 



'110 



USER MODE 



(ACCESS). 



74 



KERNEL MODE 



(OBJECT ID). 



(RESULT) 



x 

OBJECT 
MANAGER 



SECURITY 
MECHANISM 



OPERATING 
SYSTEM 



78 



It 



35 



FIG. 9 



06/05/2003, EAST Version: 1.03.0002 



U.S. Patent Oct. 23, 2001 Sheet 11 of 11 US 6,308,274 Bl 



FIG. 11 1100 GfiD 



Create Restricted Token 

* 

Associate Restricted Token with 
Process; Process Requests Access to 
Resource; Perform Access Evaluation 




06/05/2003, EAST Version: 1.03.0002 



US 6,308,274 Bl 
1 2 

LEAST PRIVILEGE VIA RESTRICTED ^ e resource. If there are no restricted security identifiers in 

TDKENS me restricted token, access is determined by the result of this 

first comparison. If there are restricted security identifiers in 
FIELD OF THE INVENTION me restricted token, a second access check for this action 

5 compares the restricted security identifiers against the list of 
The invention relates generally to computer systems, and identifiers and actions associated with the resource. With a 
more particularly to improvements in security for computer token having restricted security identifiers, the process is 
systems. granted access to the resource only if both the first and 

second access checks pass. 

BACKGROUND OF THE INVENTION 1Q Application programs may have restriction information 

._ 4 . . , * i . - stored in association therewith. When the application is 

In , computing, if a task is performed by a user having more launched a restricted token is for that application 

privileges than necessary to do that task there is an ba ^ on ^ restriction information, fa this manner, reduced 
increased risk that the user inadvertently will do some harm acccgs fa automatically cn f orc ed for that application. Appli- 
to computer resources. By way of example, if a set of files catioQS may be divided int0 different aocess levels such as 
can only be deleted by a user with administrator privileges, is privileged and non-privileged portions, thereby automati- 
then an administrator may inadvertently delete those files ca iiy restricting the actions a user can perform via that 
when performing another task that does not need to be application. Also, the system may enforce running with 
accomplished by an administrator. If the administrator had reduced access by running user processes with a restricted 
been a user having lesser privileges, then the intended task token, and then requiring a definite action by the user to 
could still have been performed but the inadvertent deletion 20 specifically override actions that are restricted by tempo- 
would not have been allowed. rarily rurining with the user's normal token. 

Thus, a recognized goal in computer security is the Other advantages will become apparent from the follow- 

concept of least privilege, in which a user performing a task ing detailed description when taken in conjunction with the 

should run with the absolute minimum privileges (or drawings, in which: 

identities, such as group memberships) necessary to do that * nPSPRlPTTON OF THE DRAWINGS 

task. However, there is no convenient way to add and BKlfcb DbM.KlKllUN ut ihlii ukawiinus 

remove a user's access rights and privileges. For example, in pjQ j ^ a block d^am representing a computer system 

the Windows NT operating system, when the user logs on, int0 the prcsent invention may be incorporated; 

an access total is built for the user based on the user's representing the 

credentials. Hie access token determines the access rights 30 q{ a rcstricted tok ^ frc f m an e 4 tir f g tokcn; 8 



and privileges that the user will have for that session. As a 



result, the user will have those privileges for each task FIG. 3 is a block diagram generally representing the 

attempted during that session and for any future sessions. various components for deterrmmng whether a process may 

While ideally an administrator can set up multiple identities access a resource; 

and log-on as a different user with different rights for each 3S FIGS. 4A-4B comprise a flow diagram representing the 

task, this is too burdensome and too complicated. Moreover, general steps taken to create a restricted token from an 

since there is no automatic enforcement, even a safety- existing token; 

conscious administrator is unlikely to log off and log back on pjQ. 5 is a block diagram generally representing a process 

with a new identity each time a different task is performed, having a restricted token associated therewith attempting to 

simply to avoid the possibility of doing some unintended ^ access a resource; 

action. FIG. 6 is a block diagram generally representing the logic 

In short, there is simply not a convenient way to change f or determining access to an object of a process having a 

privilege levels or access rights, nor a way to further restrict restricted token associated therewith; 

privileges at a granularity finer than that created by the nG 7 ^ a flow diagraiI1 representing the general steps 

domain administrator. Other operating systems have similar when determining whether to grant a process access to 

problems that make running with least privileges an ideal 43 a resource* 

that is rarely, if ever, practiced. nG 8 ^ a blodc diz&2m of various components for 

SUMMARY OF THE INVENTION automatically running an apgjc^ pi^am wkh reduced 

privileges in accordance with one aspect 01 the present 

Briefly, the present invention provides a mechanism to 50 invention; 

enforce least privilege, or in some way reduced access, via FIG. 9 is a block diagram generally representing a process 

restricted access tokens. Restricted access tokens enable a having a restricted token automatically associated therewith 

security mechanism to determine whether a process has attempting to access a resource in accordance with one 

access to a resource based on a modified, restricted version aspect of the present invention; 

of an existing access token. The restricted token is based on ^ pIG. 10 is a diagram representing an application program 

an existing token, and has less access than that token. A split into privileged and non-privileged portions in accor- 

restricted token may be created from an existing (parent) dance with one aspect of the present invention; and 

token by changing an attribute of one or more security FIG. 11 is a is a flow diagram representing general steps 

identifiers that allow access in the parent token to a setting to eoforce a user running with reduced access in 

that denies access in the restricted token and/or removing accordanC e with one aspect of the present invention, 

one or more privileges from the restricted token that are oO 

present in the parent token. In addition, restricted security DETAILED DESCRIPTION 

identifiers may be placed in the restricted token. Exemplary Operating Environment 

In use, a process is associated with a rcstricted token, and FIG. 1 and the following discussion are intended to 

when the restricted process attempts to perform an action on provide a brief general description of a suitable computing 

a resource, a kernel mode security mechanism first compares 6S environment in which the invention may be implemented, 

the user-based security identifiers and the intended type of Although not required, the invention will be described in the 

action against a list of identifiers and actions associated with general context of computer-executable instructions, such as 
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program modules, being executed by a personal computer. computers typically include other peripheral output devices 
Generally, program modules include routines, programs, (not shown), such as speakers and printers, 
objects, components, data structures and the like that per- The personal computer 20 may operate in a networked 
form particular tasks or implement particular abstract data environment using logical connections to one or more 
types. Moreover, those skilled in the art will appreciate that 5 remote computers, such as a remote computer 49, The 
the invention may be practiced with other computer system remote computer 49 may be another personal computer, a 
configurations, including hand-held devices, multi- server, a router, a network PC, a peer device or other 
processor systems, microprocessor-based or programmable common network node, and typically includes many or all of 
consumer electronics, network PCs, minicomputers, main- the elements described above relative to the personal corn- 
frame computers and the like. The invention may also be puter 20, although only a memory storage device 50 has 
practiced in distributed computing environments where 10 been illustrated in FIG. 1. The logical connections depicted 
tasks are performed by remote processing devices that are in FIG. 1 include a local area network (LAN) 51 and a wide 
linked through a communications network. In a distributed area network (WAN) 52. Such networking environments are 
computing environment, program modules may be located commonplace in offices, enterprise-wide computer 
in both local and remote memory storage devices. networks, Intranets and the Internet. 

With reference to FIG. 1, an exemplary system for imple- 15 When used in a LAN networking environment, the per- 

menting the invention includes a general purpose computing sonal computer 20 is connected to the local network 51 

device in the form of a conventional personal computer 20 through a network interface or adapter 53. When used in a 

or the like, including a processing unit 21, a system memory WAN networking environment, the personal computer 20 

22, and a system bus 23 that couples various system com- typically includes a modem 54 or other means for establish- 

ponents including the system memory to the processing unit 20 ing communications over the wide area network 52, such as 

21. The system bus 23 may be any of several types of bus the Internet The modem 54, which may be internal or 

structures including a memory bus or memory controller, a external, is connected to the system bus 23 via the serial port 

peripheral bus, and a local bus using any of a variety of bus interface 46. In a networked environment, program modules 

architectures. The system memory includes read-only depicted relative to the personal computer 20, or portions 

memory (ROM) 24 and random access memory (RAM) 25. 25 thereof, may be stored in the remote memory storage device. 

A basic input/output system 26 (BIOS), containing the basic It will be appreciated that the network connections shown 

routines that help to transfer information between elements are exemplary and other means of establishing a communi- 

within the personal computer 20, such as during start-up, is cations link between the computers may be used, 

stored in ROM 24. The personal computer 20 may further The General Security Model 

include a hard disk drive 27 for reading from and writing to 30 The preferred security model of the present invention is 
a hard disk, not shown, a magnetic disk drive 28 for reading described herein with reference to the Windows NT security 
from or writing to a removable magnetic disk 29, and an model. Notwithstanding, there is no intention to limit the 
optical disk drive 30 for reading from or writing to a present invention to the Windows NT operating system, but 
removable optical disk 31 such as a CD-ROM or other on the contrary, the present invention is intended to operate 
optical media. The hard disk drive 27, magnetic disk drive 35 with and provide benefits with any mechanism that performs 
28, and optical disk drive 30 are connected to the system bus security checks at the operating system level. 
23 by a hard disk drive interface 32, a magnetic disk drive In general, in the Windows NT operating system, a user 
interface 33, and an optical drive interface 34, respectively. performs tasks by accessing the system's resources via 
The drives and their associated computer-readable media processes (and their threads). For purposes of simplicity 
provide non-volatile storage of computer readable 40 herein, a process and its threads will be considered concep- 
instructions, data structures, program modules and other tually equivalent, and will thus hereinafter simply be 
data for the personal computer 20. Although the- exemplary referred to as a process. Also, the system's resources, 
environment described herein employs a hard disk, a remov- including files, shared memory and physical devices, which 
able magnetic disk 29 and a removable optical disk 31, it in Windows NT are represented by objects, will be ordi- 
should be appreciated by those skilled in the art that other 45 narily referred to as either resources or objects herein, 
types of computer readable media which can store data that When a user logs on to the Windows NT operating system 
is accessible by a computer, such as magnetic cassettes, flash and is authenticated, a security context is set up for that user, 
memory cards, digital video disks, Bernoulli cartridges, which includes building an access token 60. As shown in the 
random access memories (RAMs), read-only memories left portion of FIG. 2, a conventional user-based access 
(ROMs) and the like may also be used in the exemplary 50 token 60 includes a UserAndGroups field 62 including a 
operating environment. security identifier (Security ID, or SID) 64 based on the 
A number of program modules may be stored on the hard user's credentials and one or more group IDs 66 identifying 
disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, groups (e.g., within an organization) to which that user 
including an operating system 35 (preferably Windows NT), belongs. Toe token 60 also includes a privileges field 68 
one or more application programs 36, other program mod- 55 listing any privileges assigned to the user. For example, one 
ules 37 and program data 38. A user may enter commands such privilege may give an administrative-level user the 
and information into the personal computer 20 through input ability to set the system clock through a particular applica- 
devices such as a keyboard 40 and pointing device 42. Other tion programming interface (API). Note that privileges over- 
input devices (not shown) may include a microphone, ride access control checks, described below, that are other- 
joystick, game pad, satellite dish, scanner or the like. These 60 wise performed before granting access to an object 
and other input devices are often connected to the processing As will be described in more detail below and as generally 
unit 21 through a serial port interface 46 that is coupled to represented in FIG. 3, a process 70 desiring access to an 
the system bus, but may be connected by other interfaces, object 72 specifies the type of access it desires (e.g., obtain 
such as a parallel port, game port or universal serial bus read/write access to a file object) and at the kernel level 
(USB). A monitor 47 or other type of display device is also 65 provides its associated token 60 to an object manager 74. 
connected to the system bus 23 via an interface, such as a The object 72 has a kernel level security descriptor 76 
video adapter 48. In addition to the monitor 47, personal associated therewith, and the object manager 74 provides the 
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security descriptor 76 and the token 60 to a security mecha- 
nism 78. The contents of the security descriptor 76 are 
typically determined by the owner (e.g., creator) of the 
object, and generally comprise a (discretionary) access con- 
trol list (ACL) 80 of access control entries, and for each 
entry, one or more access rights (allowed or denied actions) 
corresponding to that entry. Each entry comprises a type 
(deny or allow) indicator, flags, a security identifier (SID) 
and access rights in the form of a bitmask wherein each bit 
corresponds to a permission (e.g., one bit for read access, 
one for write and so on). The security mechanism 78 
compares the security IDs in the token 60 along with the 
type of action or actions requested by the process 70 against 
the entries in the ACL 80. If a match is found with an 
allowed user or group, and the type of access desired is 
allowable for the user or group, a handle to the object 72 is 
returned to the process 70, otherwise access is denied. 

By way of example, a user with a token identifying the 
user as a member of the "Accounting'* group may wish to 
access a particular file object with read and write access. If 
the file object has the "Accounting" group identifier of type 
allow in an entry of its ACL 80, and the group has rights 
enabling read and write access, a handle granting read and 
write access is returned, otherwise access is denied. Note 
that for efficiency reasons, the security-check is performed 
only when the process 70 first attempts to access the object 
72 (create or open), and thus the handle to the object stores 
the type of access information so as to limit the actions that 
can be performed therethrough. 

The security descriptor 76 also includes a system ACL, or 
SACL 81, which comprises entries of type audit correspond- 
ing to client actions that are to be audited. Flags in each entry 
indicate whether the audit is monitoring successful or failed 
operations, and a bitmask in the entry indicates the type of 
operations that are to be audited. A security ID in the entry 
indicates the user or group being audited. For example, 
consider a situation wherein a particular group is being 
audited so as to determine whenever a member of that group 
that does not have write access to a file object attempts to 
write to that file. Hie SACL 81 for that file object includes 
an audit entry having the group security identifier therein 
along with an appropriately set fail flag and write access bit. 
Whenever a client belonging to that particular group 
attempts to write to the file object and fails, the operation is 
logged. 

Note that the ACL 80 may contain one or more identifiers 
that are marked for denying users of groups access (as to all 
rights or selected rights) rather than granting access thereto. 
For example, one entry listed in the ACL 80 may otherwise 
allow members of "Group 3 " access to the object 72, but 
another entry in the ACL 80 may specifically deny 
"Group 24 " all access. If the token 60 includes the "Group^" 
security ID, access will be denied regardless of the presence 
of the "Group 3 " security ID. Of course to function properly, 
the security check is arranged so as to not allow access via 
the "Group 3 M entry before checking the "DENY ALL" status 
of the Groups entry, such as by placing all DENY entries at 
the front of the ACL 80. As can be appreciated, this 
arrangement provides for improved efficiency, as one or 
more isolated members of a group may be separately 
excluded in the ACL 80 rather than having to individually 
list each of the remaining members of a group to allow their 
access. 

Note that instead of specifying a type of access, a caller 
may request a MAXI MUM_ALLO WED access, whereby 
an algorithm determines the maximum type of access 
allowed, based on the normal UserAndGroups list versus 
each of the entries in the ACL 80. More particularly, the 
algorithm walks down the list of identifiers accumulating the 
rights for a given user (i.e., OR-ing the various bitmaps). 
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Once the rights are accumulated, the user is given the 
accumulated rights. However, if during the walkthrough a 
deny entry is found that matches a user or group identifier 
and the requested rights, access is denied. 
Restricted Tokens 

A restricted token is created from an existing access token 
(either restricted or unrestricted) as described below. As also 
described below, if the restricted token includes any 
restricted security IDs, the token is subject to an additional 
access check wherein the restricted security IDs are com- 

10 pared against the entries in the object's ACL. Restricted 
tokens are also described in the copending U.S. Patent 
Application entitled "Security Model Using Restricted 
Tokens" assigned to the same assignee as the present 
invention, filed concurrently herewith and incorporated by 

15 reference in its entirety. 

The primary use of a restricted token is for a process to 
create a new process with a restricted version of its own 
token. The restricted process is then limited in the actions it 
may perform on resources. For example, a file object 
resource may have in its ACL a single restricted SID 

20 identifying the Microsoft Word application program, such 
that only restricted processes having the same Microsoft 
Word restricted SID in its associated restricted token may 
access the file object. Then, for example, un trusted code 
such as downloaded via a browser could be run in a 

25 restricted process that did not have the Microsoft Word 
restricted Security ID in its restricted token, preventing that 
code's access to the file object. 

For security reasons, creating a process with a different 
token normally requires a privilege known as the SeAs- 

30 signPrimaryToken privilege. However, to allow processes to 
be associated with restricted tokens, process management 
allows one process with sufficient access to another process 
to modify its primary token to a restricted token, if the 
restricted token is derived from the primary token. By 

35 comparing the ParentTokenld of the new process's token 
with the Tokenld of the existing process' token, the oper- 
ating system 35 may ensure that the process is only creating 
a restricted version of itself. 

A restricted token 84 has less access than its parent token, 
and may, for example, prevent access to an object based on 

40 the type of process (as well as the user or group) that is 
attempting to access the object, instead of simply allowing 
or denying access solely based on the user or group infor- 
mation. A restricted token may also not allow access via one 
or more user or group security IDs specially marked as 

45 "USE_FOR_DENY_ONLY," even though the parent 
token allows access via those SIDs, and/or may have privi- 
leges removed that are present in the parent token. 

Thus, one way in which to reduce access is to change an 
attribute of one or more user and/or group security identi- 

50 fiers in a restricted token so as to be unable to allow access, 
rather than grant access therewith. Security IDs marked 
USE JOR_J)ENY_ONLY are effectively ignored for pur- 
poses of granting access, however, an ACL that has a 
"DENY** entry for that security ID will still cause access to 

--be denied. By way of example, if the Group 2 security ID in 
the restricted token 84 (FIG. 3) is marked USE_FOR_ 
DENY_ONLY, when the user's process attempts to access 
an object 72 having the ACL 80 that lists Group 2 as allowed, 
that entry is effectively ignored and the process will have to 
gain access by some other security ID. However, if the ACL 

60 80 includes an entry listing Group 2 as DENY with respect to 
the requested type of action, then once tested, no access will 
be granted regardless of other security IDs, 

Note that access to objects cannot be safely reduced by 
simply removing a security ID from a user's token, since 

65 that security ID may be marked as "DENY" in the ACL of 
some objects, whereby removing that identifier would grant 
rather than deny access to those objects. Thus, the present 
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invention allows a SID's attributes to be modified to USE_ code that may be executed in "user mode" under a given 

FOR_DENY_ONLY in a restricted token. Moreover, no security context. For example, an application such as 

mechanism is provided to turn off this USE_FOR_ Microsoft Word may be launched from an ActiveX control, 

DENY_ONLY security check. which may be loaded into an existing process and executed. 

Another way to reduce access in a restricted token is to 5 Applications which launch other applications, such as 

remove one or more privileges relative to the parent token. Microsoft's Internet Explorer, may introduce a "trust model" 

For example, a user having a normal token with adminis- using this infrastructure. 

trative privileges may set up a system such that unless that By way of example, an application such as Internet 

user specifically informs the system otherwise, the user's Explorer can use restricted tokens to execute untrusted 

processes will run with a restricted token having no privi- 10 executable code under different processes, and control what 

leges. As can be appreciated, and as described in more detail ^ ose processes can do within the user's overall access rights 

below, this prevents inadvertent errors that may occur when amJ privileges. To this end, the Internet Explorer application 

the user is not intentionally acting in an administrative crcatcs a restricted token from its own token, and determines 

capacity. Similarly, programs may be developed to run in which restr i c ted security IDs will be placed in the restricted 

different modes depending on a user's privileges, whereby « tokeQ ^ untruste d executable code is restricted to 

an administrative-level user has to run the program with accessing only those objects that the restricted context may 

administrative privileges to perform some operations, but access 

operate with reduced privileges to perform more basic Moreover( entries corresponding to restricted SIDs and 

operations. Again, this helps to prevent serious errore that rcstrictions ma y be placed in a field of the SACL 81 

might otherwise occur when such a user is simply attempt- 20 ^ ^ s ^ ^ SACL of a 

mg to perform normal operations but is running with ^ ^ ^ tQ ^ ^ ^ ^ 

elevated privileges. program attempts read or write access of that resource, 

Yet another way to reduce a token's access is to add and/or the use of SIDs marked USE_J r OR_DENY_ONLY 

restricted security IDs thereto. Restricted security IDs are m ay be audited. For purposes of simphdty, auditing will not 

numbers representing processes, resource operations and the be described ^ detai i hereinafter, however it can be readily 

like, made unique such as by appending a GUID or a number appreciated that the concepts described with respect to 

generated via a cryptographic hash or mapping to a GUID or access v ja restricted SIDs are applicable to auditing 

a cryptographic hash, and may include information to dis- operations 

tinguish these Security IDs from other Security IDs. _ * . . . , nr% 

aV*u u » ♦ *u • r _ t - * M ™r,«*rnv«,*> 30 To create a restricted token from an existing token, an 

Although not necessary to the invention, for convenience, J " /Aim- j 

various application programming interfaces (APIs) are pro- application programming interface (API) is provided, named 

vided to interface applications and users with Security IDs, NtFilterToken, as set forth below: 
such as to accomplish a GUID to Security ID conversion, 

represent the Security IDs in human readable form, and so ^ __ 

0D * 35 NTSTATUS 

In addition to restricting access to a resource based on the NtFnteiTokea ( 

application (process) requesting access, specific Security in handle ExistingTokenHandle, 

IDs may be developed based on likely restricted uses of a IN Flags o<j _^^ ui „_„. Af 

n c _ i o -Lm^A ^"TTQTJ IN PTOKEN_GROUPS SidsToDisable OPTIONAL, 

resource. By way of example, a Security ID such as USLU IN ptoken.prtvileges PrivnegesToDeietc optional, 

WINDOWS** would be placed m the default ACLs of 40 IN ptoken_groups RestrictingSids optional, 

graphical user interface objects to allow access thereto only out phandle NewTbkenHandle 

by a process having a corresponding SID in its restricted ); 

token. Similarly, the default ACL of a printer object may 

include a "USE_PRINTING" SID in its default ACL, so 

that a process could create a restricted process with only this 45 The NtFilterToken API is wrapped under a Win32 API 

Security ID listed in its restricted token, whereby the named CreateRestrictedToken, further set forth below: 

restricted process would be able to access the printer but no 

other resource. As can be appreciated, numerous other 

Security IDs for accessing other resources may be imple- w^advapi 

mented. 50 BOOL 

As shown in FIG. 3, restricted security IDs are placed in apientry 

a special field 82 of a restricted token 84, such as for CreatcResuictedTokea ( 

identifying a process that is requesting an action. As ™ HA^LE^EzistingTokenHandle, 

described in more detail below, by requiring that both at m dword oSeSidCouni, 

least one user (or group) security ID and at least one 55 in psid _and attributes sidsToDisabie optional, 

restricted security ID be granted access to an object, an in dword DelctePtivilegeCount, 

object may selectively grant access based on a requesting IN PLUID_AND_ATTRIBUTES PrivUegesToDcletc 

process (as well as a user or group). For example, an object » . ■ ♦ *e-An ♦ 

such as a file object may allow Microsoft Word, Microsoft £ ^S^T^^ss^^ ophonal 

Excel or Windows Explorer processes to access it, but deny out PHANDLE NcwTbkenHandie 

access to any other process. Moreover, each of the allowed 60 ^. 

processes may be granted different access rights. 

The design provides for significant flexibility and grami- _ ^ ^ A „ T a , 

larity within the context of a user to control what different As represented in FIGS. 2 and 4A-^B, these APIs 86 

processes are allowed to do. One expected usage model for work in conjunction to take an existing token 60, either 
these features includes a distinction between trusted appli- 65 restricted or unrestricted, and create a modified (restricted) 

cations and untrusted applications. Note that the term "appli- token 84 therefrom. The structure of a restricted token, 

cation" is used in a generic sense to describe any piece of which contains the identification information about an 



06/05/2003, EAST Version: 1.03.0002 



US 6,308,274 Bl 



10 



instance of a logged-on user, includes three new fields, 
ParentTokenld, RestrictedSidCount and RestrictedSids 
(shown in boldface below): 



Typcdef struct _TOKEN { 

TOKEN_SOURCE TokenSource; // Ro: 16- Bytes 

LUID Takenld; // Ro: 8-Bytes 

LUID Authentication^; // Ro: 8-Bytcs 

LUID ParentTokenld; // Ro: 8-Bytes 

LARGE_INTEGER ExpirationUme; // Ro: 8-Bytes 

LUID Modifiedld; // Wr: 8-Bytcs 

ULONG UserAndGroupCount; // Ro: 4-Bytes 

ULONG RestrictedSidCount; // Ro: 4-Bytes 

ULONG PrivilcgeCount; // Ro: 4-Bytcs 

ULONG VariableLength; // Ro: 4-Bytes 

ULONG DynamicChargcd; // Ro: 4-Bytcs 

ULONG DynamicAvailablc; // Wr: 4-Bytcs (Mod) 

ULONG DefeultOwnerlndex; // Wr: 4-Bytes (Mod) 
PSID _^AND _JffTRB3UTES UserAndGroups; // Wr: 4-Bytes (Mod) 

PSID _JVND ..ATTRIBUTES RestrictedSids; // Ro: 4-Bytes 

PSID PrimaryGroup; // Wr: 4-Bytcs (Mod) 

PLUID _AND _ATTRIBUTES Privileges; // Wr: 4-Bytes (Mod) 

PULONG DyaamicPart; // Wr: 4-Bytcs (Mod) 

PACL DcfaultDacl; // Wr: 4-Bytcs (Mod) 

TOKEN_TYPE TokenType; // Ro: 1-Byte 

SECURITY _JMPERSONATION_LEVEL // Ro: 1-Byte 
ImpersonatiocLevel; 

UCHARTokenFlags; // Ro: 4-Bytes 

BOOLEAN TokenlnUse; // Wr: 1-Byte 

PS ECURITY_TOKEN_J > ROXY_D ATA // Ro: 4-Bytes 
Proxy Data; 

PSECURrrY_TOKEN_AUDIT_DATA // Ro: 4-Bytes 
AuditData, 

ULONG VariablePart; // Wr: 4-Bytes (Mod) 
} TOKEN, * PTOKEN; 
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Note that when a normal (non-restricted) token is now 
created, via a CreateToken API, the RestrictedSids field is 
empty, as is the ParentTokenld field. 

To create a restricted token 84, a process calls the Cre- 
ateRestrictedToken API with appropriate flag settings and/or 
information in the input fields, which in turn invokes the 
NtFilterToken API. As represented beginning at step 400 of 
FIG. 4A, the NtFilterToken API checks to see if a flag named 
DISABLE_MAX_SIDS is set, which indicates that all 
Security IDs for groups in the new, restricted token 84 
should be marked as USE FOR DENY ONLY. The flag 
provides a convenient way to restrict the (possibly many) 
groups in a token without needing to individually identify 
each of the groups. If the flag is set, step 400 branches to step 
402 which sets a bit indicating USE_FOR_DENY__ONLY 
on each of the group security IDs in the new token 84. 

If the DISABLEJVLAX^JSIDS flag is not set, then step 
400 branches to step 404 to test if any security IDs are 
individually listed in a SidsToDisable Field of the NtFilter- 
Token API. As shown at step 404 of FIG. 4A, when the 
optional SidsToDisable input field is present, at step 406, 
any Security IDs listed therein that are also present in the 
UserAndGroups field 62 of the parent token 60 are indi- 
vidually marked as USE_FOR_DENY_ONLY in the 
UserAndGroups field 88 of the new restricted token 84. As 
described above, such Security IDs can only be used to deny 
access and cannot be used to grant access, and moreover, 
cannot later be removed or enabled. Thus, in the example 
shown in FIG. 2, the Group 2 security ID is marked as USE 
FOR_DENY_ONLY in the restricted token 84 by having 
specified the Group 2 security ID in the SidsToDisable input 
field of the NtFilterToken API 86. 



token 84 should be removed. If set, step 410 branches to step 
412 which deletes all privileges from the new token 84. 

If the flag is not set, step 410 branches to step 414 wherein 
the optional PrivilegesToDelete field is examined. If present 
when the NtFilterToken API 86 is called, then at step 416, 
any privileges listed in this input field that are also present 
in the privileges field 68 of the existing token 60 are 
individually removed from the privileges field 90 of the new 
token 84. In the example shown in FIG. 2, the privileges 
shown as "Privilege^' to "Privilege^," have been removed 
from the privileges field 90 of the new token 84 by having 
specified those privileges in the PrivilegesToDelete input 
field of the NtFilterToken API 86. In keeping with one aspect 
of the present invention, as described above, this provides 
the ability to reduce the privileges available in a token. The 
process continues to step 420 of FIG. 4B. When creating a 
restricted token 84, if SEDs arc present in the RestrictingSids 
input field at step 420, then a determination is made as to 
whether the parent token is a normal token or is itself a 
restricted token having restricted SIDs. An API, IsToken- 
Restricted is called at step 422, and resolves this question by 
querying (via the NtQuerylnformationToken API) the 
RestrictingSids field of the parent token to see if it is not 
NULL, whereby if not NULL, the parent token is a restricted 
token and the API returns a TRUE. If the test is not satisfied, 
the parent token is a normal token and the API returns a 
FALSE. Note that for purposes of the subsequent steps 426 
or 428, a parent token that is restricted but does not have 
restricted SIDs (i.e., by having privileges removed and/or 
USE_FOR_DENY__ONLY SIDs) may be treated as being 
not restricted. 

At step 424, if the parent token is restricted, step 424 
branches to step 426 wherein any security IDs that are in 
both the parent token's restricted Security ID field and the 
API's restricted Security ID input list are put into the 
restricted Security ID field 92 of the new token 84. Requir- 
ing restricted security IDs to be common to both lists 
prevents a restricted execution context from adding more 
security IDs to the restricted Security ID field 92, an event 
40 which would effectively increase rather than decrease 
access. Similarly, if none are common at step 426, any token 
created still has to be restricted without increasing the access 
thereof, such as by leaving at least one restricted SID from 
the original token in the new token. Otherwise, an empty 
45 restricted SIDs field in the new token would indicate that the 
token is not restricted, an event which would effectively 
increase rather than decrease access. 

Alternatively, if at step 424 the parent token is determined 
to be a normal token, then at step 428 the RestrictingSids 
field 92 of the new token 84 is set to those listed in the input 
field. Note that although this adds security IDs, access is 
actually decreased since a token having restricted SIDs is 
subject to a secondary access test, as described in more 
detail below. 

Lastly, step 430 is also executed, whereby the Parent- 
Tokenld 93 in the new token 84 is set to the Tokenld of the 
existing (parent) token. This provides the operating system 
with the option of later allowing a process to use a restricted 
version of its token in places that would not normally be 
allowed except to the parent token. 

Turning an explanation of the operation of the invention 
with particular reference to FIG. 5-7, as represented in FIG. 
5, a restricted process 94 has been created and is attempting 
to open a file object 70 with read/write access. In the security 
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The filter process then continues to step 410 of FIG. 4A, 

wherein a flag named DISABLE _M AX_PRI VILEGES is 65 descriptor of the object 72, the ACL 80 has a number of 

tested. This flag may be similarly set as a convenient security IDs listed therein along with the type of access 

shortcut to indicate that all privileges in the new, restricted allowed for each ID, wherein "RO" indicates that read only 
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access is allowed, "WR" indicates read/write access and whereby as described above, an algorithm walks through the 

"SYNC" indicates that synchronization access is allowed. ACL 80 determining the maximum access. With restricted 

Note that "XJones" is specifically denied access to the object tokens, if any type of user or group access at all is granted, 

72, even if "XJones" would otherwise be allowed access the type or types of access rights allowable following the 

through membership in an allowed group. Moreover, the 5 user and groups run is specified as the desired access for the 

process 94 having this token 84 associated therewith will not second run, which checks the RestrictedSids list. In this way, 

be allowed to access any object via the "Basketball" security a restricted token is certain to be granted less than or equal 

ID in the token84, because this entry is marked "DENY" to access than the normal token. 

(i.e., USE_FOR_DENY_ONLY). Lastly, it should be noted that the security model of the 
For purposes of security, restricted security contexts are 10 present invention may be used in conjunction with other 
primarily implemented in the Windows NT kernel. To security models. For example, capability-based security 
attempt to access the object 72, the process 94 provides the models residing on top of an operating system may be used 
object manager 74 with information identifying the object to above the operating system-level security model of the 
which access is desired along with the type of access present invention. Indeed, capabilities may be implemented 
desired, (FIG. 7, step 700). In response, as represented at 15 as restricted SIDs. 
step 702, the object manager 74 works in conjunction with Least Privilege Via Restricted Tokens 
the security mechanism 78 to compare the user and group In general, the present invention is directed to the sys- 
security IDs listed in the token 84 (associated with the tern's automatic enforcement of a user running with reduced 
process 94) against the entries in the ACL 80, to determine access rights and/or privileges. For purposes of simplicity, as 
if the desired access should be granted or denied. 20 used hereinafter, the terms "access" or "privileges," when 
As generally represented at step 704, if access is not used in the context of the ability of a process to use a 
allowed for the listed user or groups, the security check resource, refers to either privileges or security identifiers, or 
denies access at step 714. However, if the result of the user some combination of both. Thus, a restricted token has 
and group portion of the access check indicates allowable reduced "access" with respect to its parent token's access, 
access at step 704, the security process branches to step 706 25 either by having one or more privileges removed and/or 
to determine if the restricted token 84 has any restricted having SIDs set to USE JOR_J)ENY_ONLY. A restricted 
security IDs. If not, there are no additional restrictions, token may also have reduced access if the parent token is a 
whereby the access check is complete and access is granted normal user-based token and the restricted token has 
at step 712 (a handle to the object is returned) based solely restricted SIDs therein, or if the parent token itself includes 
on user and group access. In this manner, a normal token is 30 restricted SIDs and the (child) restricted token has fewer 
essentially checked as before. However, if the token includes restricted SIDs therein. Similarly, as used hereinafter, run- 
restricted security IDs as determined by step 706, then a ning with increased or elevated "privileges" will be the same 
secondary access check is performed at step 708 by com- as running with increased "access " even though the 
paring the restricted security IDs against the entries in the increased access may actually result from security IDs in the 
ACL 80. If this secondary access test allows access at step 35 token rather than via actual privileges listed in the token. 
710, access to the object is granted at step 712. If not, access In any event, a first way in which least (i.e., in some way 
is denied at step 714. reduced) privileges may be enforced is to logically connect 
As logically represented in FIG. 6, a two-part test is thus restrictions to applications. More particularly, restricted 
performed whenever restricted Security IDs are present in execution contexts allow the operating system to create 
the token 84. Considering the security IDs in the token 84 40 separate restricted security IDs for each application, as well 
and the desired access bits 96 against the security descriptor as for each resource. The operating system may then include 
of the object 72, both the normal access test and (bitwise a secure application launcher that knows what resources an 
AND) the restricted security IDs access test must grant application needs to access, and via a restricted token, limit 
access in order for the process to be granted access to the the application (i.e., its processes) to accessing only those 
object. Although not necessary to the invention, as described 45 resources. 

above, the normal access test proceeds first, and if access is Thus, in accordance with another aspect of the present 

denied, no further testing is necessary. Moreover, it should invention and as represented in FIG. 87 an application 

be noted that a token may include multiple sets of restricted program 110 (FIG. 8) may have restriction information 112 

SIDs, with a Boolean expression in the ACL covering the associated therewith. For example, applications may be 

evaluation of those SIDs. For example, to grant access to a 50 shipped with default restrictions, and/or an administrator or 

resource, an ACL may specify that "access must be granted the like may set restrictions therefor when installing the 

to set A OR (set B AND set C)." Note that access may be application. The information 112 may include restrictions 

denied either because no security ID (or set of SIDs) in the such as which files or directories the application may access, 

token properly matched an identifier in the ACL, or because whether the application needs an administrator to run it, or 

an ACL entry specifically denied access to the token based 55 whether the application needs to launch any other programs, 

on a security identifier therein. The system stores this restriction information 112 in a 

Thus, in the example shown in FIG. 5, no access to the database, or other non-volatile memory or the like. For 

object 72 will be granted to the process 94 because the only example, a program launcher 114 such as Windows Explorer 

Restricted SID in the token 84 (field 92) identifies "Internet may store the information in its explorer link files. 

Explorer," while there is no counterpart restricted SID in the 60 When run, the program launcher 114 reads the restriction 

object's ACL 80. Although the user had the right to access information 112, and based on the stored information, ere- 

the object via a process running with a normal token, the ates a restricted token 122 from the normal, user-based token 

process 94 was restricted so as to only be able to access 116. As a result, the application program 110 is restricted to 

objects having an "Internet Explorer" SID (non-DENY) in accessing only those resources 124 to which the restricted 

their ACLs. token 122 allows access. For example, via the restricted 

Note that instead of specifying a type of access, the caller token 122, a game program 110 may be restricted to only 

may have specified MAXIMUM^\LLOWED access, accessing its own data files. 
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To this end, as shown in FIG. 9, the restricted token 122 qualified user needs to do a task that requires increased 

includes in its restricted SIDs field a restricted SID that access, the user or the operating system needs to perform an 

identifies the application, e.g., shown as "GAME33" in FIG. explicit operation to obtain that access. To this end, a user 

9. As also shown in FIG. 9, the ACL associated with each of having processes associated with a restricted token may 

the game's data files (e.g., the resource object 124) include 5 temporarily have his or her processes associated with a 

* TT " v f , m , 0 «p A wc«i\ n rrf . token (restricted or normal) having increased access. Once 

one or more identifiers (also ^ » OfJgJ '> me ^ is performed, the enhanced access is then removed 

sponding to the rcstncte^ SID or SIDs placed in the P* ^ ^ ^ ^ 

restricted token 122. When he access evaluation is * u ^ ^ how a ^ Q ^ 0Q 

performed, as described above, the application 110 will be ^ ^ of , Q ^ beginning at step 

granted access to this file object 124 because both the user 10 im & rcstricted tokcn & crcatcd for a ^ mat has less 

SID and restricted SID match entries in the security descnp- ftCcess ^ mat normal token ^ described above, 

tor. However, as determined by the administrator via the ^ ^ accomplished by changing the attributes of user and 

operating system 35, the security descriptors of other files in group SIDs t0 TjSE_FOR_DENY_ONLY, removing one 

the system lack such a "GAME33" SID, thereby preventing or morc privileges and/or adding restricted SIDs to the 

the game program 110 from accessing those other files. 15 restricted token with respect to the normal parent token. 

Another use is to control viruses by granting an applica- Then, at step 1102, the restricted token is associated with the 

tion access only to the one file being edited instead of range user's restricted process. As also shown at step 1102, when 

of files. In this manner, a macro virus is effectively stopped the process attempts to access a resource, an access evalu- 

by not letting the document access other documents. ation is performed, using the restricted token against the 

Yet another way in which to restrict access to an appli- 20 security descriptor of the resource, as described above. Note 

cation is by separating the application itself into restricted that more than two levels of restriction are feasible, (e.g., a 

and non-restricted portions. Of course, the application may normal token, a first restricted token created from the normal 

have additional granularity and be separated into more than token and a second restricted token created from the first 

two portions based on restriction levels. By way of example, restricted token). If more than two levels are desired, the 

as shown in FIG. 10, an application program 130 may have 25 restricted token associated with the process at step 1102 is 

its functions divided between administrative and non- typically me one with me least access. The user thus defaults 

administrative types of activities. In this manner, an admin- to using a reduced (e.g., the lowest possible) access level for 

istrator running with elevated privileges will be able to each task. 

perform such tasks as adding new features to the application At step 1104, the operating system (i.e., the security 
or setting its defoult behavior. Note that via restricted tokens, 30 mechanism therein) determines whether access (of the 
this may be accomplished in any number of ways, such as desired type) is allowed, and if so, branches to step 1120 
by denying access to non-administrators to dynamic link where the appropriate type of access is granted and the task 
libraries (DLLs) containing certain functions and/or the data performed. Note that when restricted SIDs are present and 
files that store the default information. Another way is to access is not via a privilege, the access evaluation comprises 
associate a token with each process that each function 35 the two-part access check as described above, 
attempts to perform, e.g., restricted token for functions In keeping with the invention, if at step 1104 access is not 
designated as non-privileged and a normal token for privi- allowed, instead of denying access, the operating system 
leged functions. In any event, ordinary users having less may give the user an additional opportunity to access the 
access will be able to perform normal functions such as resource using a token with increased access. To this end, 
entering and saving data, while higher-level user will be able 40 step 1106 tests to determine if the user's token is a restricted 
to perform administrative-like functions. Of course, some token. This determination may be made via the token's 
functions may be logically in both groups by allowing ParentTokenID field, since a restricted token has a non- 
access thereto by any type of valid user. NULL parent token identified in that field. If the token does 

Note that the separate portions may be mutually exclusive not have a parent (step 1106), then access is immediately 

with respect to access. For example, using restricted tokens, 45 denied at step 1122 since the user does not have access rights 

such as to grant or deny access to certain functions for with his or her normal token regardless of any restrictions, 

administrators, the application may be written such that Alternatively, if the token has a parent at step 1106, the 

administrators will not be able to perform normal functions system prompts the user at step 1110 to determine whether 

when running in the administrative mode, and vice-versa. the user wants to try accessing the resource again at an 

This prevents an administrator who is performing non- 50 increased access level, i.e., with the restricted token's parent 

administrative tasks in the normal mode (e.g., entering data) token. In this manner, a user is made aware of a possibly 

from inadvertently doing some damage (e.g., deleting files) dangerous situation, i.e., something extraordinary is pend- 

via a privileged function. Further, to highlight the mode of ing. If the user decides not to attempt to perform the task 

operation, the application may have a different appearance with increased access, step 1112 branches to step 1122 where 

(e.g., a different color scheme) depending on the mode in 55 access is denied. However, if the user decides that the action 

which it is being run. is indeed desirable, (e.g., do indeed attempt to delete all files 

Moreover, the present invention provides the ability to on a disk drive), the user responds aflirmatively to the 

specify that no program can normally be run with adminis- prompt, whereby step 1112 branches to step 1114 wherein 

trator privileges. This may be enforced by requiring the user the access is increased by associating the parent token with 

to launch programs with administrator privileges from a 60 the process, and the evaluation again performed. If access is 

secure desktop (i.e., one managed by the operating system). allowed (step 1116), the requested task is performed at step 

This forces the user to explicitly use administrative privi- 1118. If access is not allowed at step 1116, step 1106 is again 

leges instead of just trusting the programs. performed to determine if the token has a parent token. In 

Yet another way to ensure that a user operates with least this manner, more than two levels of restrictions are sup- 

(or in some way reduced) privileges is to have the system 65 ported. 

default such that each user runs with a restricted token Note that the above-described mechanism is not for the 

granting only a necessary amount of access. In general, if a purpose of denying access to a qualified user, but rather is 
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for the purpose of warning the qualified user that an event 
requiring a higher access level has been requested. The user 
must take a second, definite action before the event will be 
performed. However, in any situation, the user has no 
additional rights above those granted by the user's normal 
token. 

Thus, for example, an administrator will set up a restricted 
token for running his or her tasks. The restricted token 
restricts the administrator to running with the privileges and 
access rights granted to non-administrators of the group. 
Once set up in this manner, as described above, the admin- 
istrator cannot inadvertently do something to damage the 
system (e.g., delete all files on a disk drive), without being 
prompted that the requested action is at a higher level than 
for ordinary users. The prompt and response mechanism 
ensures that only a specific override will allow the 
administrative-level action. 

As can be seen from the foregoing detailed description, 
there is provided an improved security model that enforces 
operation with least (or in some way reduced) privileges via 
restricted tokens. The enforcement is automatic, and may, 
for example, be based on the application, written into the 
application and/or provided by the system via a prompt and 
response mechanism. 

While the invention is susceptible to various modifica- 
tions and alternative constructions, certain illustrated 
embodiments thereof are shown in the drawings and have 
been described above in detail. It should be understood, 
however, that there is no intention to limit the invention to 
the specific forms disclosed, but on the contrary, the inten- 
tion is to cover all modifications, alternative constructions, 
and equivalents falling within the spirit and scope of the 
invention. 

What is claimed is: 

1. In a system having a security mechanism that deter- 
mines access to resources based on information in an access 
token against security information associated with each of 
the resources, a method of restricting the access of an 
application to system resources, comprising, storing restric- 
tion information with respect to the application, the restric- 
tion information related to access of the application to the 
resources, receiving a request to run the application, creating 
a restricted access token based on the parent token and the 
restriction information, the restricted access token providing 
reduced access with respect to a parent access token, and 
associating the restricted token with the application. 

2. The method of claim 1 further comprising running the 
application, and attempting to access the system resources 
using the restricted token as the access token of the appli- 
cation. 

3. The method of claim 1 wherein storing restriction 
information with respect to the application includes identi- 
fying at least one file to which the application has access. 

4. The method of claim 3 wherein storing restriction 
information with respect to the application includes limiting 
the application to one file. 

5. The method of claim 1 wherein storing restriction 
information with respect to the application includes identi- 
fying at least one other application that the application may 
launch. 

6. The method of claim 1 wherein creating a restricted 
access token includes, copying access information from the 
parent token into the restricted token, and adding at least one 
restricted security identifier to the restricted token. 

7. The method of claim 6 wherein adding at least one 
restricted security identifier to the restricted token includes 
adding a restricted security identifier corresponding to the 
application. 
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8. The method of claim 1 wherein creating a restricted 
access token includes copying access information from the 
parent token into the restricted token, and removing at least 
one privilege from the restricted token relative to the parent 

5 token. 

9. The method of claim 1 wherein creating a restricted 
access token from the parent token includes changing 
attribute information of a security identifier in the restricted 
token to use for deny only access via that security identifier, 
relative to attribute information of a corresponding security 
identifier in the parent token. 

10. The method of claim 9 wherein separating at least 
some of the functions of an application into at least two 
groups includes, separating the functions into privileged and 
non-privileged portions, wherein associating the restricted 

15 token with at least one of the groups includes associating the 
restricted token with the non-privileged portion, and further 
comprising associating the parent token with the privileged 
portion. 

11. A computer-readable medium having computer- 
20 executable instructions for performing the method of claim 

1. 

12. In a system having a security mechanism that deter- 
mines access of processes to resources based on information 
in an access token associated with each of the processes 

25 against security information associated with each of the 
resources, a method of restricting the access of an applica- 
tion's functions to system resources, comprising, separating 
at least some of the functions of an application into at least 
two groups, creating an access token for each group, at least 

30 one of the access tokens being a restricted token having 
reduced access relative to a parent token, and associating the 
restricted token with at least one of the groups of functions. 

13. A computer-readable medium having computer- 
executable instructions for performing the method of claim 

35 12. 

14. In a system having a security mechanism that grants 
or denies a process access to a resource by comparing 
information in an access token associated with the process 
against information in an access control list associated with 

40 the resource, a method of attempting to access the resource, 
comprising, creating a restricted access token from a parent 
token, the restricted token having less access than the parent 
token, receiving a request to grant the process access to the 
resource, attempting to access the resource with the 

45 restricted token, and if access is denied, attempting to access 
the resource with the parent token. 

15. The method of claim 14 wherein attempting to access 
the resource with the parent token includes receiving a 
response from a user of the system. 

50 16. The method of claim 15 further comprising prompting 
the user for the response. 

17. The method of claim 14 wherein the parent token has 
a higher parent token with increased access relative thereto, 
and wherein attempting to access the resource with the 

55 parent token further includes attempting to access the 
resource with the higher parent token if the system denies 
access to the parent token. 

18. The method of claim 14 wherein creating a restricted 
access token from a parent token includes removing at least 

60 one privilege from the restricted token relative to the parent 
token. 

19. The method of claim 14 wherein creating a restricted 
access token from a parent token includes changing attribute 
information of a security identifier in the restricted token to 

65 use for deny only access via that security identifier, relative 
to attribute infbrmation of a corresponding security identifier 
in the parent token. 
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20. The method of claim 14 wherein the parent token is a 
normal token, and wherein creating a restricted access token 
from a parent token includes adding a restricted security 
identifier to the restricted token relative to the parent token. 

21. The method of claim 14 wherein the parent token is a 
restricted token having at least one restricted security iden- 
tifier therein, and wherein creating a restricted access token 
from a parent token includes removing at least one restricted 
security identifier firom the restricted token relative to the 
parent token. 

22. The method of claim 14 wherein attempting to access 
the resource with the restricted token includes associating 
the process with the restricted token. 

23. The method of claim 14 wherein attempting to access 
the resource with the parent token includes associating the 
process with the parent token. 

24. A computer-readable medium having computer- 
executable instructions for performing the method of claim 
12. 

25. A system, comprising, 

a set of resources, each resource having security infor- 
mation associated therewith; 

a set of restriction information associated with a request- 
ing entity and related to access of the requesting entity 
to the resources; 

a mechanism configured to create a restricted access token 
from a parent access token and the set of restriction 
information, and to associate the restricted access token 
with a process of the requesting entity, the restricted 
access token having reduced access relative to the 
parent access token; and 

a security mechanism configured to determine access of 
the process to a resource in the set of resources based 
on information in the restricted access token against the 
security information associated with that resource. 

26. The system of claim 25 wherein the requesting entity 
comprises an application program. 

27. The system of claim 25 wherein the mechanism 
configured to create the restricted access token comprises a 
program launcher. 

28. The system of claim 25 wherein the security mecha- 
nism is incorporated into an operating system. 

29. The system of claim 25 wherein the restriction infor- 
mation identifies at least one file. 

30. A system, comprising, 

a set of resources, each resource having security infor- 
mation associated therewith; 

a set of access tokens including a parent access token and 
at least one restricted access token created from the 
parent access token and having reduced access relative 
to the parent access token; 

a requesting entity; 

a mechanism configured to determine a selected access 
token from the set of access tokens based on an 
operating mode of the requesting entity and a process 
corresponding to the operating mode, and to associate 
the selected access token with the process; and 

a security mechanism configured to determine access of 
the process to a resource in the set of resources based 



on information in the selected access token against the 
security information associated with that resource. 

31. The system of claim 30 wherein the requesting entity 
comprises an application program. 

32. The system of claim 31 wherein the application 
program includes a plurality of operating modes, each 
operating mode having at least one application function 
corresponding thereto. 

33. The system of claim 30 wherein the mechanism 
configured to determine the selected access token comprises 
a program launcher that evaluates restriction information 
associated with the requesting entity. 

34. The system of claim 30 wherein the mechanism 
configured to determine the selected access token deter- 
mines as the selected access token a first restricted access 
token on a first attempt to access the resource, and deter- 
mines as the selected access token a second access token on 
a second attempt to access the resource. 

35. The system of claim 34 wherein the second access 
token comprises the parent access token. 

36. The system of claim 30 wherein the security mecha- 
nism is incorporated into an operating system. 

37. A computer-implemented method, comprising, 
selecting a selected access token from a set of access 

tokens, the set of access tokens including a parent 
access token and at least one restricted access token 
created from the parent access token and having 
reduced access relative to the parent access token; 
associating the selected access token with a process of an 
requesting entity, the requesting entity capable of 
requesting access to a set of resources; and 
providing the selected access token to a security mecha- 
nism upon a request by the requesting entity for access 
to a resource of the set, the security mechanism deter- 
mining access of the process to the resource based on 
the selected access token and security information 
associated with the resource. 

38. The method of claim 37 wherein selecting a selected 
access token includes detennining an operating mode of the 
requesting entity. 

39. The method of claim 37 wherein selecting a selected 
access token includes determining a function to be executed 

45 by the requesting entity. 

40. The method of claim 37 further comprising creating a 
restricted access token based on restriction information 
associated with the requesting entity. 

41. The method of claim 37 wherein selecting a selected 
50 access token includes determining that a previously selected 

access token has been denied access to the resource. 

42. The method of claim 37 wherein selecting a selected 
access token includes determining that a previously selected 
access token, has been denied access to the resource, and 

55 receiving a request to attempt access with another access 
token. 

43. A computer-readable medium having computer- 
executable instructions for performing the method of claim 
37. 
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